Mob Testing是一種強調團隊共創與即時回饋的高階測試活動。其核心概念是「整個團隊在同一時間、同一地點、圍繞同一台電腦，共同針對同一個測試任務進行探索」。這項實踐將原本可能被視為單調的驗證工作，轉化為一個集學習、趣味、探索與高度投入於一體的思維過程，透過跨職能成員的參與，讓測試不再是個人的單打獨鬥。

在群測的環境中，團隊會分配不同的角色來維持運作，通常包含操作設備的執行者（Driver）、觀察全局並引導方向的導航者（Navigator），以及在旁觀察並隨時提供不同領域見解的群眾（The Mob）。這種模式的主要目的在於借鑒大家的測試經驗與靈感，從而打破個人的認知盲點，因為每個人在評估風險與方法時難免存在侷限，而群測正好能將這些零散的觀點匯聚成完整的風險防線。

此外，群測不僅是為了找出 Bug，更具備深層的團隊教育意義。由於包含測試、開發、產品經理甚至設計師等不同背景的人員共同參與，它能促進測試經驗的即時分享，並幫助資淺或非測試背景的成員在實際操作中快速掌握測試思維。這種高度互動且自由的氛圍，除了能強化測試團隊的凝聚力，更能讓團隊成員在探索中建立對產品質量的共同信心。

Mob Testing這項實踐並非憑空出現，而是深受 極限編程（Extreme Programming, XP） 中「結對編程」（Pair Programming）的啟發，並將其範圍由兩人擴展至整個團隊。

這項概念最早由 Woody Zuill 在 2011 年左右正式推廣Mob Programming。最初的動機是為了解決團隊成員在開發過程中遇到的溝通斷層，以及知識過於破碎的問題。當時發現，當整個團隊（包括開發與測試人員）圍繞在同一台設備前工作時，能夠大幅減少決策的等待時間，並達到即時的同儕審閱效果。

隨後，這套模式被測試社群（Testing Community）引入並優化為Mob Testing）。測試專家們發現，測試工作不僅僅是個人的驗證任務，更是一個需要集體智慧、學習、趣味與高度投入的思維過程。在這種情境下，透過跨職能成員（如產品經理、設計師與開發者）的共同參與，能將零散的個人測試靈感匯聚成系統化的風險防線。

Mob Testing之所以可行且強大，其核心邏輯在於透過「集體智慧」來熨平個人表現的波動，確保測試品質的高度穩定。以下從幾個角度為您解析其可行性：

(1) 消除個人狀況的波動
如下圖表所示，個人的工作狀況（Quality）會隨著專注力、疲勞度或認知偏誤而起伏，有時處於高點，但有時會掉入低谷。在低谷期，容易遺漏關鍵 Bug 或誤判需求細節。

當參與人數增加到「兩個人」或「一群人」時，每個人的品質曲線雖各有起伏，但彼此的低谷鮮少重疊。透過協作，團隊整體的品質輸出（圖中粗紅線）能維持在相對的高標，不再受限於單一測試員當下的狀況。

(2) 彌補認知的盲點
協作型探索式測試認為每個人都有自己的盲點。Mob Testing讓不同職能（開發、測試、PO）圍繞同一個任務，能即時借鑒大家的經驗與靈感。

在Mob Testing流程中，當執行者遇到規格不明或流程阻礙時，團隊成員（群眾）就在現場，能透過一句提示立即化解僵局，避免測試路徑因個人卡關而中斷。

(3) 持續的高強度投入（Engaged Exploration）
防範發散與深陷：Mob Testing透過「導航者」與「群眾」的監督，能有效控制測試方向，避免個人因過度自由而深陷於非核心功能的細節中。

探索式測試是個集「學習、趣味、探索、投入」為一體的思維過程。在群體氛圍下，這種投入感會被放大，有利於測試經驗的即時分享與團隊凝聚力。

Mob Testing 的流程可分為以下 9 個具體步驟：

(1) 引導者開啟會議的進行：由引導者（Designated Navigator）發起並確保測試會議順利啟動。

(2) 先找好特派領航員和司機：確定本次測程中負責操作的司機（Driver）以及負責產生測試想法的特派領航員。

(3) 每次配對 N 分鐘：設定固定的時間循環（例如每 N 分鐘一次），確保角色能持續輪換。

(4) 司機負責執行和紀錄：司機根據領航員的想法操作受測產品，並同步紀錄測試過程。

(5) 特派領航員說測試想法：領航員產出測試思路，但不親自動手操作，而是與其他領航員討論後下達指令。

(6) 時間到後，特派領航員變司機：當設定的配對時間結束，原先的特派領航員轉換角色成為實際操作的司機。

(7) 下一個領航員變成特派領航員：隊伍中的下一位參與者接手，成為新的特派領航員。

(8) 重複 3-7 直到測試時間到：持續循環上述的角色切換與測試執行，直到該測程預定的總時間結束。

(9) 召開回顧會議檢討：最後進行成果回顧與反饋，檢討測試過程中的發現與待改進事項。

這個流程透過不斷的角色輪換，將「特派領航員」的構思與「司機」的執行分離，並集結現場所有參與者的智慧，達成高效的協作型測試。

以下我們來看一個業界實際案例，作者 Jan Jaap Cannegieter 與 Michel van ‘t Zant 完整分享了他們在實際專案中，導入與實驗Mob Testing的經驗。以下為他們使用Mob Testing的詳細經驗整理與各階段的演進：

(1) 專案背景與導入契機
作者在參加了幾場測試研討會後受到啟發，決定在一個非營利組織的專案中實驗Mob Testing。該專案的目標是替換組織的「核心系統」，這套系統涵蓋了從採購、交付到計費的主要業務流程。測試團隊的組成相當多元，不僅包含專業的測試人員，還加入了一群經過培訓的實際系統使用者。

(2) 破除懷疑：第一次Mob Testing的奇效
在初期，開發人員與使用者對Mob Testing抱持著懷疑的態度。主要原因是雙方平時缺乏互動，且專案中存在許多長期未解、在雙方之間來回「踢皮球」的缺陷（不斷經歷開啟、解決、拒絕解決方案、重新測試、再次開啟的惡性循環）。為了突破這個僵局，他們舉辦了第一次Mob Testing，結果獲得了巨大的成功：

A. 解決長期缺陷：在這次會議中，他們一口氣解決了十幾個長期存在的缺陷。

B. 促進理解與直接溝通：許多缺陷其實根本不需要修改程式碼，只需透過「解釋」就能解決——例如開發人員向使用者解釋如何用另一種方式完成任務，或是使用者向開發人員說明他們的實際工作流程。而真正需要修改系統的缺陷也立即得到了處理。

C. 打破團隊隔閡：有趣的是，許多開發者和使用者在會議開始時才互相自我介紹，顯示他們以前根本不認識彼此。這次經驗大大改善了雙方關係，他們後來甚至開始直接聯絡彼此，而不再被動等待測試會議。面對面的直接溝通成為了這次Mob Testing最大的收穫。

(3) 第二種變體：類似「Bug Hunt」的結對測試
在第二種變體的實驗中，團隊事前準備了一份全域的測試案例清單，並讓大約 6 位使用者以「兩人一組」的方式進行結對測試，每組負責一個測試案例。

A. 執行方式與學習：有時他們會在測試前與所有參與者討論特定案例的觀察重點。他們在實踐中學到，將某些測試案例「分組」會更有效率，特別是當前一個測試案例的結束狀態剛好是下一個測試案例的起點時。

B. 缺陷討論：在測試過程中若發現嚴重的缺陷，他們會統一保留到會議結束時才進行討論。

團隊在後續的Mob Testing中嘗試邀請了高階管理層參與，這帶來了明顯的優缺點：

A. 最大優點就是掌握進度：管理者能清楚掌握專案的實際進度，並深刻理解為何當下「不宜將系統上線」。這讓管理者能親自在指導委員會中有理有據地解釋延遲上線的原因，而不再只依賴測試經理的報告。

B. 最大缺點就變成是拖慢節奏：部分管理者會在會議中針對早已定案且無法更改的流程設計、系統設計及工作方式重啟爭論，這嚴重拖慢了測試的節奏。

C. 後續對策：基於上述缺點，團隊決定不再邀請高階管理層全程參與Mob Testing。取而代之的是，透過定期的報告與系統展示（Demo）來同步進度，或者只邀請他們參與會議最後的「缺陷討論階段」。

(4) 第三種變體：開發人員的「精準參與」
在這個變體中，團隊嘗試讓開發人員融入Mob Testing，但為了不浪費開發資源，他們並不需要全程在場。

A. 流程設計：開發人員會在會議一開始先向大家展示要測試的系統部分，隨後離開去處理自己的工作，並在最後半小時重新加入以討論大家發現的缺陷。

B. 建立信任感：討論完畢後，開發人員會直接修復這些缺陷。這種高效率的處理方式大幅提升了使用者對系統的信任感。作者再次強調，面對面的溝通消除了許多誤解，這依然是Mob Testing帶來最大的好處。

(5) 端到端（End-to-End）測試與顛覆傳統的高層展示
團隊還發展出另一種變體，主要用於測試不同系統之間的互動（雖然他們當時不稱其為Mob Testing，但具備相同的核心精神）。

A. 跨系統的信心建立：會議中召集了所有底層系統的代表。由一位「駕駛員（driver）」發動測試案例，各系統代表則緊盯並檢查該案例在自己負責的系統中是否被正確處理。這讓所有代表都對系統的正確運行充滿了無比的信心。

B. 自然而然的「上線決策」：團隊後來利用這部分的測試規格，向組織的高階管理層進行系統展示。他們刻意使用「已知絕對會通過」的測試案例來進行展演，因為其目的不是為了找 Bug，而是向組織證明系統能夠完美支援其業務流程。高層親眼看到系統順利運作後，甚至主動詢問「何時可以上線」。這種基於第一手觀察的決策方式，成功取代了傳統由測試經理撰寫的「發布建議報告（release advice）」，讓上線決策變得水到渠成。

作者最終的建議是：如果你認為Mob Testing能在你的組織或專案中帶來價值，就勇敢地開始嘗試。最重要的是要「持續實驗，不斷嘗試新事物」，藉由在實踐中不斷摸索與調整變體，最終找出最適合自身團隊情境的運作模式。